perm filename THESIS.MTG[RDG,DBL] blob
sn#606845 filedate 1981-08-18 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00019 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 ∂19-Jun-81 1827 STT AI thesis conspiracy meets Tuesday
C00006 00003 ∂20-Jun-81 1419 STT mailing list for AI thesis conspiracy
C00008 00004 ∂25-Jun-81 1239 STT arrangements for discussion groups
C00012 00005 ∂25-Jun-81 1247 STT no meeting of "red" group this Friday, unless...
C00013 00006 ∂25-Jun-81 1501 STT room change
C00014 00007 ∂28-Jun-81 1804 SJW Abstract for Black group meeting next Tuesday
C00017 00008 ∂29-Jun-81 2211 SEK
C00025 00009 ∂06-Jul-81 1109 TGD Black meeting (Tues 10 am, MJH 301)
C00031 00010 ∂09-Jul-81 1449 TGD RED meeting tomorrow
C00037 00011 ∂13-Jul-81 1726 CPP Tuesday's Black Group Meeting
C00042 00012 ∂16-Jul-81 2007 STT red group meeting tomorrow
C00045 00013 ∂22-Jul-81 1352 STT abstract advice
C00046 00014 ∂22-Jul-81 1712 GAC Friday meeting
C00052 00015 ∂28-Jul-81 1309 TGD BLACK thesis group needs speakers
C00053 00016 ∂02-Aug-81 1351 AAM Black group
C00055 00017 ∂10-Aug-81 1356 MJM Joint group meeting on THURSDAY, Aug.13, MJH 301
C00058 00018 ∂12-Aug-81 0156 BIK via AMES-TIP
C00063 00019 ∂15-Aug-81 1923 NCR
C00068 ENDMK
C⊗;
∂19-Jun-81 1827 STT AI thesis conspiracy meets Tuesday
To: "@THESIS.LST[1,STT]" at SU-AI
Several of us PhD students in AI think it would be useful to get together
in a sort of seminar to discuss our thesis ideas. The main goal is to give
each of us a convenient and more or less friendly audience for our ideas
and plans. Secondarily we get to hear what everybody else is doing.
Participants are expected to be at least at the stage of seriously
considering some ideas, and willing to talk about them at one of the
meetings.
The format will be roughly this: We'll meet for about an hour, once a week.
The person for that week makes some sort of brief presentation to get the
discussion started, and has the primary responsibility to keep it focussed.
Handouts may be useful. (The best group size is probably four to six, and
if we get more we might split up. This message is being sent to quite a few
people.)
The first meeting will be held 10:00 am next Tuesday, June 23, on the fourth
floor balcony of MJH. If you can't make it then but are interested, send
a message to STT@SAIL. At the first meeting Steve Tappel has volunteered
to talk about his "problem reformulation" ideas.
∂TO STT 15:48 21-Jun
See you there.
Yes, I'll come this Tuesday. Also, I got your message requesting I
postpone posting posters. What's the reason?
Russ
∂20-Jun-81 1419 STT mailing list for AI thesis conspiracy
To: "@THESIS.DIS[1,STT]" at SU-AI
Rich Pattis suggested people might like to know who was in the distribution
list for the meeting Tuesday. Here's the full list. Have we left anybody out?
The main instigators of the meeting are Tom Dietterich and myself. People
marked with an asterisk participated in a somewhat similar discussion group
last summer and fall.
csd.bennett@score, Jim Bennet
csd.berlin@score, Danny Berlin
klc@sail, Ken Clarkson *
csd.pcohen@score, Paul Cohen
cooper@sumex, Greg Cooper *
jed@sail, Jim Davidson
csd.dietterich@score, Tom Dietterich *
csd.jjf@score, Jeff Finger
avg@sail, Anne Gardner
csd.genesereth@score, Mike Genesereth * (token faculty)
rdg@sail, Russ Greiner *
konolige@sri, Kurt Konolige
kunz@sumex, John Kunz
dlo@sail, Dave Lowe *
ml@sail, Mike Lowry
jdm@sail, Jock Mackinlay
aam@sail, Allan Miller
rep@sail, Rich Pattis
csd.cpp@score, Chuck Paulson *
ncr@sail, Neil Rowe
csd.smith@score, Dave Smith *
stt@sail, Steve Tappel *
csd.cht@score, Chris Tong *
yue@sail Kai-Zhi Yue
∂25-Jun-81 1239 STT arrangements for discussion groups
To: "@THESIS.DIS[1,STT]" at SU-AI
About thirteen people attended the "thesis conspiracy" meeting this Tuesday.
We have split into two groups, called "red" and "black" after the manner in
which they were chosen.
All of you who aren't in a group yet are invited to join one, by sending a
message to the relevant coordinator. See below.
Each group will meet once a week. At each meeting one of the members will
introduce some of their thesis ideas (or possibly other research ideas) and
lead a discussion about them. Bull sessions and colloquium-style talks are
both to be avoided. If I may offer some advice, which would have been helpful
for my talk & discussion Tuesday, it is important to:
(1) Carefully choose a topic which people can reasonably be expected to have
something to say about,
(2) Give some concrete examples or whatever to center the discussion around,
and
(3) Try to hold people to the topic.
The person who's going to talk and lead the discussion should send around a
short abstract beforehand, to the entire mailing list THESIS.DIS[1,stt] at SAIL.
(This gives members of the group a chance to think about the issues to be
raised and gives members of the other group a chance to attend if they're
specially interested. If you don't have access to the mailing list send your
abstract to one of the coordinators, who will forward it.)
"RED" GROUP
Meeting time & place: Friday 10:00 am, MJH 252
Coordinator: Steve Tappel (STT@SAIL)
Members so far:
Mike Genesereth
Russ Greiner
Beverly Kedzierski
Scott Kim
Rich Pattis
Steve Tappel
Chris Tong
"BLACK" GROUP
Meeting time & place: Tuesday 10:00 am, MJH 252
Coordinator: Tom Dietterich (CSD.DIETTERICH@SCORE)
Members so far:
Jim Bennet
Tom Dietterich
Anne Gardner
John Kunz
Mike Lowry
Marsha Meredith
Steve Westfold
∂25-Jun-81 1247 STT no meeting of "red" group this Friday, unless...
To: "@THESIS.DIS[1,STT]" at SU-AI
Scott Kim says this Friday is out for him. So unless some other red group
member is ready to talk and sends around an abstract TODAY, there will be
no meeting tomorrow. Do we have a volunteer?
Scott is rescheduled for next Friday.
∂25-Jun-81 1501 STT room change
To: "@THESIS.DIS[1,STT]" at SU-AI
The powers that be don't want us to use room 252, since it's the nicest room.
Therefore our meetings will be held in room 301 instead, same time, for both
the "red" and "black" groups.
∂28-Jun-81 1804 SJW Abstract for Black group meeting next Tuesday
To: "@THESIS.DIS[1,STT]" at SU-AI
Beyond Interlisp:
Building a Programming Environment Around a Very-High-Level Language
Stephen Westfold
Tuesday 10:00am, MJH 301
In the CHI project at SCI we are exploring the idea of applying knowledge
based programming techniques to the programming tools themselves in order
to produce more flexible, powerful, better tools. A major premise of
the work is the desirability of very-high-level languages (these include,
for example, operations on abstract datatypes such as sets and relations).
The problem with such languages is that they are difficult to compile into
efficient code using standard techniques. The approach we (and others)
take to this problem is one of step-wise refinement whereby high-level
constructs are successively transformed into lower-level constructs using
transformation rules, possibly with some search.
In my thesis work I hope to develop and demonstrate the practicality of
this approach. One reason for choosing parts of the system itself as
targets is that they are real, practical programs that we are using and
developing, so that any inadequacies in the approach will tend to be obvious.
A more important reason is the feeling that the advantages of very-high-level
language programming will make the tools significantly better as tools.
An example that I have been developing is the specification in rules of
our rule compiler.
∂29-Jun-81 2211 SEK
To: "@THESIS.DIS[1,STT]" at SU-AI
Meta-metafont:
Some radical thoughts on computer graphics and programming languages.
Scott Kim
Friday 10:00am, MJH 301
My thesis project will be to build a successor to Metafont. Metafont is a
programming language built by Knuth for designing typefaces--the output of
a Metafont program is a set of character images represented as bit
matrices. My system will also be used for designing typefaces, but the
style of interaction will be very different. Metafont is a batch-oriented
language, whereas my system will be intrinsically interactive.
The project has two primary goals:
(1) The first goal is practical: The system should be useful to actual
typeface designers. This means a great deal of attention to the user
interface, involving careful study of how designers actually work as well
as good criticism.
(2) The second goal is more theoretical and far less understood. Every
computer graphics language that I know of is in fact textual: the output
is pictures, but the language that represents the output is made of typed
characters. Since program and data are in different forms, the language
cannot have the power model itself. In Lisp, program and data are both
represented as lists, and this uniformity leads to a richness that is not
found in weaker computer languages. What I want to explore further is the
possibility of a language in which program and data are both graphical.
I don't know what the implications of such a paradigm shift will be, but
I have the strong feeling that it is both possible and valuable.
Friday I want to discuss some of the issues which have come up in the
course of pondering the question "What is a programming language?" I will
present a number of systems which are almost but not quite programming
languages and ask how the differences can be classified. The discussion will
venture far beyond the usual taxonomy of finite-state automata and Turing
machines, into areas which I find exciting but disorienting.
∂From SEK 12:56PM 3-Jul
Here are some scattered memories from Friday July 3's thesis consipiracy.
Please feel free to add observations and questions which were of particular
interest to you.
David:
Beverly: referring to negative space. Isn't this related to work in
animation: key frame interpolation? This is a bit far-fetched, but what
about the SF image of a dusty alien library full of books that contain
pictures and sounds, but no words? Image of a moldable clay terminal.
Dan: (imagining an actual terminal interaction) there would be a period of
time in which you agree on what refers to what, e.g. what you mean when
you refer to the left bar of an A. You draw the picture, then attach
names.
Russ: Fortran feels closed--there are things which you really can't say in
the language. For instance you can't talk about numbers in TEX. Lisp, in
contrast, feels more open. I understand why you might want graphical
arguments, but why graphically represented function names?
Steve: We already have a graphic expressive language: gestures.
Marsha: That's funny; instead of shaving off the bottom of the stroke of
the A, I thought of pushing something in.
Scott: My language should have multiple representations of what a
character is (pixel, outline, stroke, area). A complete graphics language
should include a vision system, so that the language is able to refer to
what the user can see. What should I call my language, a graphical
graphics language? Image: Fortran do loop represented more and more
graphically (substitute diagrams and symbols for numbers and letters),
contrasted with letter A represented more and more textually (add
annotations to clarify the meaning of a drawing). The first image gives
you the misleading impression that a graphical language is nothing but a
picture-coated respresentation of what is actually a textual language. In
fact, some things are more appropriately represented as pictures, and it
is precisely those things which I expect would benefit from a graphically
based language. I want to do for graphics what Lisp does for symbol
manipulation.
Image I didn't give in the lecture: graphics languages are virtually
always based on textual languages. Example: letter shapes coded in
Metafont. Actually there are lower levels (assembly language,
physics...), but we can seal them off, ignore them, and still get what
feels like a complete understanding of what's going on. I want to reverse
the emphasis: a language which bottoms out on graphics.
∂06-Jul-81 1109 TGD Black meeting (Tues 10 am, MJH 301)
To: "@THESIS.DIS[1,STT]" at SU-AI
Black group meeting, Tuesday Jul 7, 10 am in MJH 301.
Discussion person: Tom Dietterich
I am currently trying to formulate a thesis proposal on learning.
Most current learning programs start with an expert-supplied
set of terms (features, predicates, etc.) and connectives (AND, OR, NOT)
and search the space of possible sentences written using the terms and connectives
for a sentence (concept, rule, etc.) that is consistent with the training instances
and that satisfies some other constraints (simplicity, plausibility, etc.).
I am interested in attempting to have a program rationally select the terms
and connectives (i.e., the description language) to search. I would
like to have a system come up with reasons for (and against) including each
possible term. The system could alternate between a "select terms" step
and a "learning" step. Once it selected some terms, it could conduct
the "learning search", and depending upon the outcome of that search, it could
modify its choice of terms and repeat the process. The thesis thus aims
at making explicit a body of knowledge about how to determine how some
terms are relevant to some partially understood phenomenon.
Of course, in the long run it would be desireable to have a system learn
precisely this knowledge so that it could improve its learning ability.
There are many directions the research could take, and I'd like the group
to give me advice on what domain might be suitable and on which of these
directions I should pursue:
1. The iterative approach to selecting and then learning could evolve into
a sort of combined system in which the program started with a very trivial
language and gradually expanded and modified it.
2. I could concentrate on new term invention. Could the system start with a
"vague" model of the phenomenon and by common sense reasoning and analogy
develop the relevant terms (and ways of measuring them).
3. Another approach to term invention that has received some (reletively little)
attention is the process of inventing new terms by combining old terms.
I could work on this problem. (easier than 2.)
4. Another problem in learning is learning with disjunctions. When a disjunctive
connective is added into the description language, least-committment generalization
searches such as Mitchell's candidate elimination algorithm or any of the
breadth-first algorithms explode. The solution seems to be some kind of
heuristic search and some approach to understanding exactly what
kinds of disjunction are useful/desirable.
5. Yet another set of problems are raised in situations that are noisy.
If the training instances are noisy, other knowledge must be brought to bear
to guide the search of description space.
6. The biggest area of research is probably in the strategies for suggesting
and justifying the incorporation of certain terms in the representation language.
What kinds of strategies can be used? One approach might be to make up a
"story" about how the unknown phenomenon works and then incorporate those
variables that participate in the "story". In chess endgames, for example,
a program might reason that pinning a piece against the edge of the board is
a good strategy and thus develop a set of features that measure "opportunity
to pin", etc. These features could then be used to learn from examples of
chess endgames.
∂09-Jul-81 1449 TGD RED meeting tomorrow
To: "@THESIS.DIS[1,STT]" at SU-AI
CC: darden at SUMEX-AIM
RED group meeting, Friday Jul 9, 10 am in MJH 301.
Discussion person: Tom Dietterich (YES, I'm talking to the
RED group too!)
I am currently trying to formulate a thesis proposal on learning.
Most current learning programs start with an expert-supplied set of
terms (features, predicates, etc.) and connectives (AND, OR, NOT) and
search the space of possible sentences written using the terms and
connectives for a sentence (concept, rule, etc.) that is consistent
with the training instances and that satisfies some other constraints
(simplicity, plausibility, etc.).
I am interested in attempting to have a program rationally select the
terms and connectives (i.e., the description language) to search. I
would like to have a system come up with reasons for (and against)
including each possible term. The system could alternate between a
"select terms" step and a "learning" step. Once it selected some
terms, it could conduct the "learning search", and depending upon the
outcome of that search, it could modify its choice of terms and repeat
the process. The thesis thus aims at making explicit a body of
knowledge about how to determine how some terms are relevant to some
partially understood phenomenon. This is a version of the
circumscription problem: how can the learning program circumscribe the
problem so that it can generate plausible hypotheses?
There are many directions the research could take, and I'd like the
group to give me advice on what domain might be suitable and on which
of these directions I should pursue:
1. The biggest area of research is the elucidation of strategies for
selecting relevant terms. Most previous work in this area has used
simple spreading activation in a network to select relevant terms. I
suspect that the next level of sophistication involves developing, for
each term or group of terms, a "half-baked" hypothesis about how those
terms affect the phenomenon of interest. For example, if the system
is attempting to discover what causes lung cancer, it might suspect
that airborne particles are important because the air comes into
contact with the lungs. This could lead the system to look at terms
describing properties of the air breathed by patients.
By introducing these "term relevance hypotheses", I am introducing a
second level of hypothesis formation into the learning system. These
hypotheses are different from hypotheses about what combination of
terms provides a necessary and sufficient condition for some
phenomenon to occur.
2. A second direction for research could be the development of new
terms. Existing work on new terms creates new terms by combining
previous terms using connectives such as AND, OR, FUNCTION
COMPOSITION, PROJECTION, etc. I suspect that the development of new
terms will require a deeper representation of the semantics of terms--
particularly partial definitions of terms using necessary conditions,
sufficient conditions, effects, causes, exemplars and nonexemplars,
etc.
3. A third direction for research would be learning from disjunction.
When a disjunctive connective is added to the description language,
least-committment generalization searches such as Mitchell's candidate
elimination algorithm explode. The solution seems to be some kind of
heuristic search and some approach to understanding exactly what kinds
of disjunction are useful.
4. Finally, I could focus on problems of learning in the presence of
noise and uncertain observations. Very little work has been done on
this problem.
∂13-Jul-81 1726 CPP Tuesday's Black Group Meeting
To: "@THESIS.DIS[1,STT]" at SU-AI
Chuck Paulson
July 13, 1981
Representation of Control
Programs can be thought of as consisting of three parts. They are
the data structures, the atomic operations on those data stuctures, and the
control or ordering of those operations in the program. This talk will be
concerned with the representation of the latter component.
Control has been rather opaque in traditional languages, ie. it is not
clear why a certain control structure is used and it is certainly the case that
the program itself doesn't know about its control structure, or how to change
it. Control is usually hard to modify in a given program and it is also not at
all clear how to deal with parallel operations. Lately several attempts have
been made to understand and represent control structure in order to analyze
control and give the program knowledge of its own control.
Some methods have been:
1) Traditional Programming Languages (compilers look at control flow a little)
2) Petri Net Models
3) Finite State Machine Models
4) Production Rules
5) AMORD System (MIT, by deKleer, Doyle, Rich, Steele, and Sussman)
Rule based system with TMS, pattern-directed invocation, explicit
representation of control.
6) Chuck Reiger's CSA representation. Uses a large causal network with many
different flavors of causality.
7) BDL, the DART system representation. A combination of petri nets,
procedural nets, and Reiger's rep.
8) Programmer's Apprentice Plans. Has explicit control links within a plan.
They look like railroad tracks. Plans include data links, control
links, and other plans in hierarchical fashion.
9) Sacerdoti's procedual nets. Are hierarchical, explicitly include partial
ordering of actions.
There are undoubtedly more representations which I have neglected to
include. These give a starting base from which to work outward. Some problems
in representation of control and examples of them follow:
1) Duration of operations (race conditions)
2) How ordering of operations affects resources (deadlocks)
3) Figuring out and representing constraints on partially parallel actions
(trying to optimize a pipeline or an IBM 360/91 floating point unit)
4) Transforming conceptually parallel operations into serial ones so that a
single resource can handle them.
(multi-port memory, timesharing on a computer,
this is the concept of a serial resource controller)
5) Making control easy to understand and transparent to the user
(occurs to everyone trying to understand other people's code,
PA is working on this problem)
∂16-Jul-81 2007 STT red group meeting tomorrow
To: "@THESIS.DIS[1,STT]" at SU-AI
Rich Pattis will discuss his ideas on debugger design this Friday,
at our usual meeting time and place (10:00 am, MJH 301.)
Below is a message from Rich; please note that his second abstract
is the main one for tomorrow.
-----
∂16-Jul-81 1502 KLC
Steve, here is a combination of the abstracts of the two talks I gave to
the debugging seminar. They indicate what I'll focus on during my talk
tomorrow....Rich
I plan to survey the debuggers mentioned in the reference list below. I'll
start by describing some of the features of the LISP-Machine/INTERLISP & MESA
debuggers and their interpreted/compiled environment. Then I'll review the
outstanding features of the research debuggers mentioned below, most of which
never made it into everyday use. The review will be carried out in depth,
some to the level of implementation details, as the time/information tradeoffs
made in these systems are interesting. I'd like to conduct this seminar meeting
as more of an open discussion, as opposed to a straight lecture.
I plan to present a proposal for a high level debugger, mostly concentrating
on its post-mortem aspects. I am assumming that the host machine is a large,
personal computer (ala SPICE). I will discuss issues concerning how to organize
and store the execution history of a program, and how to effectively access (with
a debugging languge) this information. I will try to convince everyone that not
a too great price (in time) must be paid for this type of debugger, and that
a large increase in debugging productivity can result.
∂22-Jul-81 1352 STT abstract advice
To: "@THESIS.DIS[1,STT]" at SU-AI
Don't take this too seriously, folks, but here is a suggested outline for
abstracts and discussions. I hope it is of some use.
your research topic
be as specific as you can
supply background if required
intended contribution to AI
current status
question to be discussed
important to your research
a question that people can realistically be expected to have ideas about
recommend that you have examples ready to focus discussion
∂22-Jul-81 1712 GAC Friday meeting
To: "@THESIS.DIS[1,STT]" at SU-AI
RED (and BLACK?) group meeting 10:00 a.m. Friday 24 July, MJH 301.
Speaker: Gray Clossman
Self-Monitoring in an AI program
I want to present a control structure that may allow a program to
monitor itself and detect loops in its behavior. This ability is necessary
for an AI program that operates in a description-rich domain by means of
redundant and potentially circular transformations on descriptions. The
Seek-Whence (SW) program, currently being implemented by MJM, DRH, and GAC,
is such a program. SW discovers and manipulates descriptions of patterns in
the toy world of integer sequences. I would like for SW to monitor itself
to the extent that it would detect loops in its behavior, and represent and
reason with that information. A loop in the behavior of SW is a recurrence
of a description that has earlier been generated by the program. Different
types of recurrences can serve as indications that the program is in a rut
(a bad loop), or that the description that has been regenerated has recurred
as a good idea that deserves more attention.
SW maintains several competing descriptions (of a sequence) and
theories (predictive rules for the sequence) as it tries to arrive at `good'
theories for the sequence. A good theory is one that many people would give
as the rule that generates the sequence. SW uses a HEARSAY-II-like Blackboard
and parallel control structure. Among the ways in which it differs from HSII
are two points of interest here:
1) The production rules for transforming information into different forms
and moving it up and down (among levels of description) on the Blackboard will
be richly redundant. Every production, P, will result in a change to the data
structures on the Blackboard. "P(a) -> b" means that if predicate <P> detects
pattern <a> on the Blackboard, then structure <b> (which is usually built from
<a>) may be asserted (i.e., linked into the Blackboard). In SW's redundant
productions, many productions will have inverses: "P(a) -> b" and "P(b) -> a".
Such productions allow -- even encourage -- loops in SW's behavior.
2) SW will not use an overseer-scheduler to notice loops and be arbitrer.
There will be no global "goal-directed scheduling function" as in HSII; no
global, wise conflict-resolver. Control will be largely in the hands of demons
(productions).
Obviously, SW must monitor its progress and avoid looping endlessly
through circular reformulations of sequence descriptions. I propose that
when a description on the Blackboard is changed (summarized, restructured, or
deleted) by a production, a new production be generated that will "recognize"
that description if it later recurs. The new production should also record
the action taken when the description was last encountered. When that
description is re-encountered, a different action may be taken.
I would like to explore the questions:
What does "to monitor self" really mean?
How does "self monitor" differ from "self model"?
I am pushing control information into representation-language
data-structures on the Blackboard so that the (concurrently-executing
sameness-detecting demons of the) program can detect patterns of behavior.
What are the implications of annotating control in the representation language?
∂28-Jul-81 1309 TGD BLACK thesis group needs speakers
To: "@THESIS.DIS[1,STT]" at SU-AI
The BLACK group needs people to volunteer to speak. So far, only
Tappel, Westfold, Dietterich, and Paulson have given talks. We'd
like to hear from the rest of you (or from anyone who wants to talk
a second time). As you are no doubt aware, the BLACK group has
not met for the past two weeks. I've been too busy to line up a
speaker for each week.
--Tom
∂02-Aug-81 1351 AAM Black group
To: "@THESIS.DIS[1,STT]" at SU-AI
I will be speaking on Tuesday, August 11 (a week from next Tues.) at 10 AM
in MJH 301. I'll talk about
. What kind of problems are being solved in computer vision research
. Why these problems need more compute power
. Ways to provide the compute power needed
. Problems associated with VLSI implementations of array processors
I have a few slides I prepared for a previous presentation. If you would like
to read something before the meeting, I wrote a short (two-page) paper which
appeared in the latest proceedings of the Image Understanding workshop. I
have reprints of this paper; see either me in room 030A or Marianne Siroker
in room 030.
Allan
∂10-Aug-81 1356 MJM Joint group meeting on THURSDAY, Aug.13, MJH 301
To: "@THESIS.DIS[1,STT]" at SU-AI
BUILDING A BASIS FOR ACTIVE CONCEPTS
The ability to classify, to make common abstractions, to reason by
analogy, to detect patterns is fundamental to human intelligence. People do this
continually, with or without conscious volition. A purse can remind us of a
pocket, a weapon, a particular person, or any number of other things. One story
reminds us of another. Such phenomena seem to point toward the existence of
"active concepts", concepts which
(1) are malleable, stretchable;
(2) can insinuate themselves into an ongoing thought process;
(3) are manipulated and operate at pre-verbal, "thought-collecting" levels.
My proposal is that an attempt can be made to construct such active
concepts in a world more amenable to analysis than natural language. The
chosen vehicle is representation of patterns expressed as integer sequences.
The SEEK-WHENCE project involves characterizing sequence patterns in terms of
S-W "diagrams", objects with both structural and procedural aspects, based on
a small group of redundant "primitive" structuring notions. The "theory" (final
predictive diagram) for a pattern is derived from the sequence of input terms
by a "Schoolhouse" system reminiscent of the HEARSAY-II architecture, but with
a few new twists. It is hoped that the process of diagram creation can be
made to leave behind a trail of active agents which, along with the final diagram,
could become the main portion of a "Concept" for that sequence. If this can
be done successfully, such notions as common abstraction, conceptual closeness,
and reminding could be studied. Certainly, a study of analogy would be
possible.
My talk will be on THURSDAY, August 13th in MJH 301. I welcome
questions, suggestions, and references.
∂12-Aug-81 0156 BIK via AMES-TIP
To: "@THESIS.DIS[1,STT]" at SU-AI
This Friday, August 14th at 10:30am in MJH 301, I will give a talk to the
Red Group (and whoever else shows up) on my Ph.D. thesis work.
The research involves the creation of a System Development Support
Environment to assist in communication and management tasks of software
project members, thus aiding in the development of large, evolutionary
systems. I am using a knowledge-based synthesis approach while dealing
with a Human Factors issue.
The environemnt should include INTEGRATED capabilities for project
management, system evaluation, documentation/help and intelligent
communication between designer/users and the system or other designers.
Collecting, organizing and dissemination information about a project,
using a model of the underlying system, raise database, knowledge
representation and interface issues, including the use of formal vs
natural languages.
The work is centered on an idea I have developed, that people perform
"Comunication Acts", such as: questioning, griping, planning, requesting
or informing, while interacting with a system. These are similar to
Speech Acts of Linguistics, and are often dealt with in Office Automation
work. A Taxonomy of these "Acts" has been created from initial, informal
experiments. They will be presented, along with the environmemt design
and framework, a scenario, workplan and progress report.
I will have slides prepared, since I have to give a presentation Monday at
Systems Control, Inc. and could use part of this talk as practice.
Actually, our group (Cordell Green, my advisor, et al) is now formally
Kestrel Institute.
My thesis topic was approved a year ago April. Since the work is so
interdisciplinary, I have approached it from many angles. There is
currently an initial implementation of some of the ideas. I have
incorporated all my written material into a report that has been submitted
for separate government funding. I may pass out the table of contents from
that report to initiate discussion.
After the initial presentation, I would appreciate feedback on questions
such as: (1) What do you, as system users and builders, imagine to be in
an ideal support environment? [For now, I am not emphasizing program
maintenace issues] and (2) Which areas of this work should be stressed and
which should be avoided? If there is time, I may pose some problems, from
data I have collected, to see how many tasks you could imagine fulfilling
as an ideal, intelligent system support environment, and in what manner
you believe the processing should take place.
∂15-Aug-81 1923 NCR
To: "@THESIS.DIS[1,STT]" at SU-AI
I will give a talk on Tuesday, August 18 at 10 A.M. in Jacks 301
to the Black group and anyone interested from the Red group. Topic: a
rule-based system to calculate descriptive statistics on a database.
The setting is an extremely large database such as a governmental
organization or large company might have. For such databases,
statistical analyses are a primary usage. But most interesting
statistical calculations require essentially random access to many
records on secondary storage, running up enormous amounts of time. A
possible solution is to precompute some descriptive statistics for
commonly asked-about sets. The problem with this is that there are just
too many such sets. An arbitrary number of sets can be combined by
intersections, unions, and complements to make new sets, and an
unlimited number of sets can be defined on a continuous-valued
attribute.
Our approach is to precompute some statistical information for simple
sets that a user might query, and try to derive statistics for other
sets from these. For instance, the statistics for American tankers are
probably something like the statistics for American ships and for
tankers. At least the largest American tanker cannot be larger than
either the largest American ship or largest tanker; and so on.
We can write a number of such rules to get statistics of complicated
sets in terms of algebraic combinations of statistics on simpler sets.
This represents a modification of the concept of "inheritance" as it is
known in AI. Modifications are necessary because statistical properties
of a sibling node rarely inherit directly from the parent; the average
American tanker length is unlikely to be the average American ship
length. Similarly, the most common cargo on an American tanker is
unlikely to be the most common cargo on an American ship.
Integrating several hundred statistical derivation rules into a
production system raises interesting questions of control architecture
which we are just starting to address. Note this production system will
be unusual in that the best of possible rules should not be "selected"
-- all possible rules should be fired in parallel, to give the tightest
possible constraints on an uncertain answer.
There are also interesting problems about queries about prototypes and
analogies. For instance, does the prototypical American tanker have the
mean size of members of its set? Or maybe the mode size? And AI does
not seem to have a notion of dispersion in the range of property values
a prototype can have, a notion which our work suggests is critical.